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ABSTRACT 



Information-centric networking proposals attract much at- 
tention in the ongoing search for a future communication 
paradigm of the Internet. Replacing the host-to-host connec- 
tivity by a data-oriented publish/subscribe service eases con- 
tent distribution and authentication by concept, while elim- 
inating threats from unwanted traffic at an end host as are 
common in today's Internet. However, current approaches 
to content routing heavily rely on data-driven protocol events 
and thereby introduce a strong coupling of the control to the 
data plane in the underlying routing infrastructure. In this 
paper, threats to the stability and security of the content dis- 
tribution system are analyzed in theory and practical exper- 
iments. We derive relations between state resources and the 
performance of routers and demonstrate how this coupling 
can be misused in practice. We discuss new attack vectors 
present in its current state of development, as well as possi- 
bilities and limitations to mitigate them. 

Categories and Subject Descriptors 

C.2.1 [Computer-Comm. Networks]: Network Ar- 
chitecture and Design — Cryptography and Security; C.2.2 
[Computer-Comm. Networks]: Network Protocols — 
Routing Protocols; C.2.6 [Computer-Comm. Net- 
works] : Internetworking — Routers 

Keywords 

Performance, Forwarding Plane, Security, Distributed 
Denial of Service (DDoS), Vulnerability, Content-centric 
Routing, Resource Exhaustion, Jamming, Named-data 
Networking 

1. INTRODUCTION 

One major dedication of today's Internet is the global 
distribution of content in huge amounts. Content dis- 
tribution networks (CDNs) facilitate an efficient, wide- 
area replication of static data for selected content pro- 
viders, whereas the end-to-end design of TCP/IP does 



not foresee implicit replication and in-network storage. 
There is no openly available network standard for the 
asynchronous, global replication of popular content in 
the current Internet. 

Inspired by the use case of widely deployed CDNs, 
current research has created the concepts of Content or 
Information- Centric Networks. We will use the acronym 
ICN to subsume the different approaches throughout 
this article. ICN abandons the current Internet model 
of connecting end nodes. Instead, it follows a data- 
oriented publish/subscribe paradigm that facilitates con- 
tent distribution and authentication by concept. In 
ICN, consumers shall retrieve content by name directly 
from a network that provides storage, caching, content- 
based rendezvous, and searching at times. 

Several proposals have been presented in recent years 
|], among them TRIAD [l], DONA (2], NDN (tj [5], 
PSIRP 6 , and Netinf [7|, which differ in several design 
choices. As we are interested in the stability and secu- 
rity of ICN infrastructures, we will concentrate on the 
aspects of routing and forwarding. 

Essentially two approaches to routing exist in cur- 
rent ICN proposals, an evolutionary path that resolves 
names to locators and routes on IP (or a related location 
scheme), and 'clean slate' concepts that route directly 
on content identities. Netinf extends the current Inter- 
net by a resolution service that maps content names to 
topological IDs like IP addresses, but alternatively sup- 
ports name-based routing. TRIAD, DONA and NDN 
perform content retrieval by routing on names. Route 
responses and the data itself are then forwarded along 
reverse paths (RPF), either by using IP as a lower layer, 
or without IP but by dedicated RPF states. PSIRP 
publishes content objects to a resolution system that 
incloses full knowledge of the network topology. Re- 
questers trigger the mapping system to generate for- 
warding identifiers, i.e., Bloom filters of aggregated link 
IDs, that are used to forward of data. 
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All solutions operate on the content itself, and force 
the network infrastructure into a content awareness. 
A mapping service is not only required to resolve file 
names to source locations, but must answer a request 
by advising a nearby replica, the existence of which 
it learned from the data distribution system. Content 
routers need to rely on (often aggregated) names in its 
interface tables and - for RPF-based forwarding schemes 
- a reverse state for every data unit. This control infor- 
mation is highly dynamic and requires regular updates 
from the data plane. The ICN paradigm thereby opens 
up the control plane to continuous modifications from 
the data plane. This is in contrast to the current Inter- 
net, where DNS and routing states remain unaltered by 
data-driven events such as file names or cache locations. 

In this paper, we study the effects of control plane be- 
haviour under various data conditions. We are in par- 
ticular interested in threats to the stability and security 
of the ICN infrastructure, whose impacts we evaluate in 
a theoretical analysis and experimental trials. Experi- 
ments arc performed in test networks running PARC's 
CCNx software. We want to stress, though, that our 
tests only attribute for the core concepts of content 
routing and do not evaluate implementation properties 
of the CCNx prototype. Following the basic insights 
gained from theoretical and practical analysis, we con- 
tribute a collection of new attacks that ground on this 
transfer from data to control states. 

The remainder of this paper is organized as follows: 
The specific problems in protecting the ICN infrastruc- 
ture are stated in § [2] along with related work on ICN 
security. We theoretically analyze basic threats to sta- 
bility in § [3] and discuss related implications. Based on 
practical experiments, threatening scenarios and their 
effects on the routing system are demonstrated in § |4j 
These general insights lead to concrete attack scenarios 
in § [5] The paper concludes with a discussion in § [6j 

2. WHY ICN IS CHALLENGED BY DESIGN 
2.1 Problem Statement 

Information-centric networking introduces two kinds 
of states into the network infrastructure, (1) content 
publications or announcements, and (2) subscriptions 
or requests for asynchronous content access. Publica- 
tion states are announced within the request routing 
system or stored in some name resolution service. Sub- 
scriptions are memorized hop by hop in reverse path 
forwarding states, in the name system, or at commu- 
nicating end nodes in IP-based systems^ In addition, 
in-network caching requires management of replicas at 

1 LIPSIN, as an exception, keeps record of subscriptions in 
the mapping/rendezvous system to construct source routing 
filters that generate distribution trees. 



content routers. These statefull operations raise the fol- 
lowing issues: 

Resource Exhaustion: Infrastructural entities need to 
offer accumulating resources like memory and pro- 
cessing power for provisioning, maintaining and 
exchanging content states. They are therefore threat- 
ened by resource exhaustion due to misuse or un- 
controlled load. 

State Decorrelation: The asynchronous nature of pub- 
lish/subscribe content delivery places the enhanced 
burden of assuring consistency among distributed 
data states. Data states that require correlation 
are situated in distributed mapping systems, which 
also need to consistently reflect actual content place- 
ments, and in forwarding states at routers that de- 
fine the paths hop-by-hop from a supplier to the 
requester. Failures in state coherence may lead to 
service disruptions or unwanted traffic flows. 

Path &: Name Infiltration: The infrastructure relies 
on the integrity and correctness of content routing 
and is therefore threatened by poisonous injections 
of paths and names, in particular. The replica- 
tive ICN environment distributes content copies to 
many, commonly untrusted locations and thereby 
makes it particularly hard to authenticate valid 
origins of state insertion requests. 

Cache Pollution: The conceptual value and the per- 
formance of the ICN infrastructure is built upon 
receiver-driven caching. It is therefore vulnerable 
to all operations that spoil the cache relevance. 

Cryptographic Breaches: Publishers, who massively 
sign long-lived content, offer time and data to an 
attacker for compromising cryptographic creden- 
tials. The asynchronous use of public key cryp- 
tography for signing large data volumes facilitates 
common attacks to breach signer's keys. 

All of these threats bear the potential to seriously 
degrade the ICN service and lead to insufficient or er- 
roneous data dissemination. Another major risk for the 
ICN infrastructure — and from a general perspective for 
the ICN concept — results from the power that an end 
user gains over an (open) ICN distribution backbone. 

2.2 End Users Affect Backbone States 

Content suppliers Related work on ICN secu- 
rity has primarily focused on validating content correct- 
ness and authenticity. Commonly, self-certifying secu- 
rity credentials arc included in 'secure names' that fa- 
cilitate mechanisms for verifying authors, origins, and 
content integrity (9j [lO) [Tl] [12] . Thus a receiver can be 
sure to obtain the correct content and an intermediate 
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cache can validate the correctness of the security cre- 
dentials, which finally prevents DoS on the ICN system 
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Nevertheless, having created (or learned) a valid 
name, any ICN member can re-announce this in the 
request routing system or re-register it in the content 
resolution service, thereby injecting poisonous routes or 
artificial names into the systemj^] Similar vulnerabili- 
ties of DNS and BGP are known from today's Internet 
but remain restricted to (topology) 
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infrastructure 

providers. ICN opens the liberty of route injection to 
the group of content suppliers (i.e., end users). We will 
discuss threats unique to ICN in Section [3~T| 

Security aspects of Internet caching have been studied 
extensively, see [15] and refs. therein. Current work has 
identified conceptual difficulties in preventing locality 
attacks, as they are hard to distinguish from regular 
user behaviour. It is worth noting that cache snooping 
raises privacy issues in ICNs, as well. We will not dive 
deeper into this well-known subject. 

Content consumers Little attention has been 
given to the effects of state management in ICN. Arian- 
far et al. |T6] discuss design choices for an ICN router. 
They concentrate on the content cache and explicitly do 



not consider per-request states. Perino and Varvello 17 



have evaluated requirements for content routers that 
hold content information bases in Bloom filters and re- 
verse paths in pending interest tables (PITs). Under 
the assumptions of valid content requests propagated 
on homogeneous network links with a maximum global 
RTT of 80 ms, average PIT sizes are identified in the 
order of 1 Gbit/s for current line speeds. FIB sizes and 
lookup complexity were shown to depend nonlincarly 
on prefix numbers and name lengths. Lauinger |18| ex- 
plicitly addresses the threat of DoS attacks by filling 
the available memory of a router with pending interest 
states. 

Such attacks on hardware resources may be mitigated 
by limiting overall PIT sizes. However, securing router 
resources by table limits does not abandon resource ex- 
haustion problems which equally occur whenever tables 
are filled. In the presence of a table limit, an attacker 
could initiate massive drops of Pis from a router's table 
and thus disrupt data delivery to regular receivers. The 
author in [18] proposes to drop interests at the head of 
the PIT, which however may easily be misused to DoS- 
attacking neighbors, or to use Bloom filters instead of 
Pis. If applied without strict capacity limits, the latter 
approach is vulnerable to flooding attacks as interface 
filters degrade their selectivity. 

Only recently, and after the first release of this tech- 



nical report and its excerpt 19 , state management and 



2 As a countermeasure, DONA introduces certificates of pub- 
lishers on the price of per cache-instance varying names. 
Content routing then works on wildcarding names, which 
re-introduces the threat of route poisoning. 



related security issues have been discussed in reports by 
Yi et al. [3] and Gasti et al. |20j. The authors discuss 
core issues of route hijacking, state overload, and cache 
pollution and propose counter measures by extending 
interface functions, e.g., for limiting rates and survey 
content delivery. We will refer to those aspects in detail 
along the lines of this article. 

Intermediate Summary ICN opens the con- 
trol plane of (ICN-enabled) backbone routers for con- 
tent consumers and suppliers (i.e., end users) on a fine- 
grained base. This is a fundamental step away from 
the current Internet design and bears significant risks. 
Current concerns in the context of routing mainly focus 
on state explosion due to the large amount of content 
items. One might argue that those resource exhaustions 
will be solved by more powerful hardware in the future. 
We will discuss options and limitations of related core 
aspects in Section [3j Still, binding the integrity of the 
routing infrastructure to end users activities is intrin- 
sic to current ICN approaches — and presumably to the 
overall ICN concept. 

3. BASIC THREATS TO STABILITY 

The control-plane in ICN will encounter changes and 
processing load for each publication and for each con- 
tent request. Publication states require management 
in the request routing or mapping system, whenever 
a content item is published/withdrawn or a cache loca- 
tion is added/removed. Subscriptions initiate a grafting 
of distribution states throughout the forwarding system 
(DONA, NDN, Netlnf) or trigger optimized path find- 
ing procedures in the resolution service (PSIRP, Net- 
lnf). 

In this section, we theoretically discuss resulting threats 
that inherently arise at the infrastructure level. 

3.1 Routing or Mapping Resources 

The common view on routing is that of a topological 
resolution service: Routing guides the paths to hosts. 
As ICN abandons the host-centric paradigm to address 
content objects directly, routes to content items attain 
the role of traditional topological directives. 

3.1.1 State and Update Complexity 

In ICN, each content item (file) needs retrieval and 
therefore must be accessible via some resolution service. 
This may either be implemented by a distributed rout- 
ing system, or by a mapping service that provides an in- 
direction to topological locators of publishers or content 
caches. The average complexity of the corresponding 
management operations reads (# of content items) ■ 
(# cached replica) ■ {update frequency) and must be 
considered a severe challenge. A global request rout- 
ing system will need to host at least the amount of the 
Google index base (O(10 12 )) at a much enhanced up- 
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date frequency (by caching). For comparison, today's 
DNS subsumes O(10 8 ) names at a very low change rate 
of s» 10 5 alterations per day. As a consequence, the 
request routing/mapping system is stressed by adding 
and updating name or cache entries at overwhelming 
frequency, the details of which depend on the imple- 
mentation of the service. 

3.1.2 Caching On-Path versus Off-Path 

Route maintenance in ICN consists of propagating 
content publishers (i.e., default paths) as well as cache 
instances. While the first task is known to generate 
a high volume of data and frequent updates, caching 
is expected to largely exceed default announcements in 
number and update frequency. As a countermeasure, 
data replication may be limited to caching along de- 
fault paths, which remarkably reduces the complexity 
for the routing system. On-path cache replica are met 
implicitly when requests are routed towards the source, 
and need not be advertised in the routing or mapping 
service. On the downside, restricting the caching to de- 
fault paths will drastically reduce its effectiveness, and 
a corresponding strategy falls behind today's CDN solu- 
tions. Godsi et al. 13 discussed the caching problems 
in detail. The authors came to the conclusion that on- 
path caching is merely a warm-up of traditional Web 
proxies. 

3.1.3 Route Integrity 

ICN, like the current Internet, relies on the integrity 
of its routing system. A bogus route may block or de- 
grade services, lead to incorrect content delivery, or vi- 
olate privacy. These core concerns are well-known from 
BGP 14 1 . Without considering protective measures 
in BGP, Yi et al. [3] and Gasti et al. 20 compare 



and Gasti et al. 
BGP with NDN security. The authors argue that the 
NDN approach reduces vulnerability to black-holing, as 
routers can identify unresolved content requests and 
rank/re-route per prefix and interface. Nevertheless, 
these countermeasures cannot prevent attacks of inter- 
ception and redirection with service degradation. 

Aside from those vulnerabilities known from BGP 
routing, the following threats uniquely arise for content- 
centric routing. 

Route Set Inflation Almost all ICN solutions allow 
for universal caching without explicit authoriza- 
tion. Any in-network cache can thus announce 
any content name, while origin validation mea- 
sures such as RPKI [21] cannot be applied. 

Route-to-Death Route redirections may be applied 
to slow down content delivery or to jitter response 
times. As the routing infrastructure is vulnera- 
ble to increased delays and delay variations, cor- 
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The i-th Router 

Capacity of the link between Ri and Ri+i 
Utilization of the link between Ri and Ri+i 
# of content request states of Ri at its in- 
terface towards R4+1 
Content request rate at interface Ri - 
Content arrival rate at interface Ri <- 
Request timeout at interface Ri — > R 
Packet length 
Average value of • 
Standard deviation of • 



Ri+l 
Ri+l 

-1 



responding threats arise (see Section 3.2) 



Table 1: Glossary of Notations 



3.2 Forwarding Resources 

Traditional routers in today's Internet consist of a 
central processing unit and main memory that are avail- 
able to the control plane, mainly to learn and deter- 
mine new routes, as well as FIB memory that is fed 
by the route selection process. Data forwarding re- 
mains bound to FIB lookup and packet processing at 
line-cards. This design choice purposefully decouples 
forwarding capacities from control processing and-with 
equal importance — protects control states from (bogus) 
data packets. 

Current concepts of content-centric data forwarding 
break with this separation paradigm, and introduce — 
similar to multicast — an additional reverse path for- 
warding table, also called PIT. Unlike in multicast, this 
table is updated packet-wise on line speed by data-driven 
events. In the following subsections, we concentrate on 
the consequences for routing resources in detail. We will 
consider a chain of routers Pi along a data path and use 
the notation summarized in Table [I] 



3.2.1 Content Request States versus Content Request 
Rates versus Network Utilization 

Content request states, i.e., Pending Interests in NDN, 
are the essential building block to flow control in a 
content-centric distribution system that operates hop- 
by-hop. Each request state will trigger a data packet 
on return, why the number of open request states cor- 
responds to data arrival at this interface after the trans- 
mission time. 

Consider a point-to-point interface between routers in 
steady operation and in the presence of a (per interface) 
state timeout Tj. In the absence of request retransmis- 
sions, packet loss, and state dismissal, we first want to 
derive the relation between router states at time t and 
network capacity. The basic rate equation reads 
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#(t) = St(t-Ti)+ Oi(T) - LJ^dr 

Jt-Ti 

= S , . 1 (t-T i )+ / aj(r) - ai(ir(T))d,T 

Jt-Ti 

= {a i )-mm({RTT),T i ) + 

O (a{ ai ) ■ a(imn(RTT,Ti))) , (1) 

where n(.) denotes the time shift corresponding to the 
packet arrival process and RTT the random variable of 
packet round trip times, which is assumed independent 
of the requests and packet rates. 

From Equation 0, we can immediately deduce that 
timeout values below the (varying) RTTs limit the num- 
ber of request states, but at the same time will block 
data forwarding. A second view reveals the strong de- 
pendence of states on the RTT variation. A similar 
phenomenon is well-known from TCP [22] , but has been 
overlooked in corresponding previous work on ICN re- 
source considerations [17] [3] [20] . 

Henceforth we will address the case of data flowing 
unhindered by the state timeout T^. Furthermore — for 
a steady-state scenario — it is assumed that the content 
request rate fluctuates on the same stationary scale. 
Equation then simplifies to 

Si(t) « (at) ■ ((RTT) + na(RTT)) (2) 
« U t (t)/(l)((RTT)+n<j(RTT)), (3) 

with an estimating parameter re for the mean devia- 
tion^] For the last step, we roughly assumed that con- 
tent requests and content arrival are in stationary equi- 
librium. 

Approximation (|3| yields the desired coupling of the 
link utilization and the state management resources at 
a router: On a single point-to-point link without state 
retransmissions and in flow balance, state requirements 
are proportional to the network utilization, enhanced by 
a factor of a global retransmission timeout. At switched 
interconnects or in bursty communication scenarios, con- 
ditions are expected to grow much worse. 

The following observations are noteworthy. 

1. Unlike in TCP that estimates a single end-to-end 
connection, content request states at routers ag- 
gregate prefixes and numerous flows to various con- 
tent prefixes. Moreover, content items (prefixes) 
are explicitly not bound to end points. Thus rapidly 
varying RTTs arc characteristic to interfaces and 



even to flows in content-centric routing. The pres- 
ence of chunk caching may even increase the RTT 
variation. Hence, no convergent estimator for a 
round trip time can be reasonably givenj^] 

In the current Internet, the variation of RTT is 
commonly larger than its average. End-to-end de- 
lays are known to approximately follow a heavy- 
tailed Gamma distribution 
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3 The corresponding (over-)estimator in TCP is commonly 
set to 4. However, it is well known that standard TCP al- 
gorithms and parameters are inefficient at rapidly changing 
round trip times, which are characteristic for interface con- 
ditions in content-centric routing. 



ports means and standard deviations of about 250 ms, 
with maxima up to 5,000 ms. 

3. Limiting the absolute size of the content request 
table imposes a strict bound on network utiliza- 
tion. However, the sustained rates are mainly de- 
termined by actual RTTs and are hardly predictable. 
Similar arguments hold for defining timeout val- 
ues. 

4. A corresponding picture arises, when content re- 
quest rates are limited instead of table sizes H For 
an 'on average' optimal limit Cj • (RTT) /(I), the 
variation of content replies in time may lead to 
large over- and under-utilization of network re- 
sources that goes along with large fluctuations in 
request table sizes. 

3.2.2 Memory Requirements 

A content-centric router that is designed to fully uti- 
lize its link capacities, requires sufficient table space 
for content requests under varying network conditions. 
Equation ([3]) approximates the corresponding resources 
when applied to the maximum link capacity C$. Using 
the conservative value of re = 4 as for TCP, a packet 
length I = 1,000 bytes, and RTT values from PingER 
as cited in the previous section, we derive 

Si = 1, 25 s/8.000bit ■ d « 1, 6 • lO^s/bit ■ C t (4) 

For a line-speed of 1 to 100 Gbit/s, 160k to 16,000k 
content request entries then need to be installed per 
interface at minimum E Due to the more accurate in- 
clusion of RTT variation terms, these findings differ 
from previous results [17| [3] by more than an order of 
magnitude. Still they are merely a rough estimate, as 
larger fluctuations of round trip times may significantly 
increase resource demands. 

It is noteworthy that Equation Q holds for any router 
in a content-centric Internet. Unlike today, where full 

4 Yi et al. [3J propose to maintain RTT estimators per pre- 
fix and interface in the FIB, which would find its analogy in 
BGP by adding RTT estimators per IP prefix. The evalua- 
tion of such quantities would not only require an extensive 
pairwise probing, but at the end is not well defined for (ag- 
gregated) prefixes. 

5 Rate limiting has been currently proposed in 13]. 

6 This number may well underestimate the need Dy an order 

of magnitude or two. 
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BGP tables are only required at AS border routers, and 
interior devices operate on a very small routing table, 
CCN access routers already demand for a full PIT mem- 
ory, the size of which is determined by its interface ca- 
pacities. In practice, this significantly increases router 
costs, as any fast interface must co-locate a large block 
of fast memory. 

3.2.3 CPU Load from Table Management 

An ICN content router maintains states according to 
user data requests. For any content request, it needs to 
(1) insert a state in its request table. On the arrival of 
any data packet, it needs to (2) search and (3) delete on 
success in the same table. These operations are required 
at line speed. In addition, a router has to (4) maintain 
timers of all (soft) states in its content request table. 

The paradigmatic shift of ICN opens the state ta- 
ble, which is responsible for data delivery, to the end 
users. Any content requester may create unexpected 
access patterns. Consequently, to guarantee robustness, 
an implementation of the request table not only needs 
to perform dictionary operations very efficiently on av- 
erage but also in worst-case. As there is no final design 
of an ICN router, we discuss the general design space 
for hash tables in this context. 

The most efficient implementation is the usage of 
on-chip content-addressable memory (CAM), which is 
the complete hardware counterpart of a dictionary data 
structure. However, costs, energy, and limited size pro- 
hibit its deployment for expected PIT tables sizes. Typ- 
ically, state tables for request routing (or caching) are 
implemented using hash tables. In its elementary form, 
these data structures can perform all basic dictionary 
operations (i.e., insert, search, and delete) at constant 
complexity, but experience hash collisions. Collisions 
cause a conflict: An implementation that ignores hash 
collisions will overwrite data. This limits the field of 
application for ICN, as dealing with collisions increases 
complexity, or making the system directly threatened 
by DoS. 

In ICN, Perino and Varvello 17 , for example, pro- 
pose to use HC-basic [25] , a collision-prone scheme with- 
out avoidance mechanisms. Such a design choice makes 
the ICN system vulnerable to (also purposefully) replac- 
ing valid content requests. In realistic deployments of 
ICN, an implementation of hash tables will either pro- 
vide mechanisms to prevent or to handle hash collisions. 

Essentially four solutions are known to overcome hash 
collisions: (1) Hash chaining or open addressing, (2) 
perfect hashing, (3) cryptographic hash functions, and 
(4) universal hashing. 

Hash chaining (i.e., concatenating conflicting keys) or 
open addressing (i.e., deterministic probing for an alter- 
nate location) [26| circumvent collisions on the price of 
enhanced update costs. The worst case complexity in- 



creases to 0(N) for a table of size N . This introduces 
well-known vulnerabilities, as any pattern that creates 
collisions will result in such linear complexity instead of 
amortized 0(1). Crosby and Wallach [27] analyzed this 
for current software systems (e.g., the Bro IDS). For the 
more sophisticated and widely deployed hardware hash 
tables Peacock and Cuckoo, Ben-Porat et al. [28] re- 
cently studied the structural vulnerability and observed 
significant performance degradation, as well. Applying 
these approaches to ICN introduces an obvious threat. 

"Perfect hashing" [26] supports constant complexity 
in the worst-case, but requires a static key set. It is 
thus not suitable for dynamic content requests that are 
characteristic in ICN. 

Collision resistant cryptographic hash functions can 
be applied, but lead to a prohibitive increase in mem- 
ory and CPU consumptions. Enabling cryptographic 
operations at backbone routers has been discussed con- 
tinuously in the context of securing BGP 14 and did 
not succeeded so far. In contrast to requests in ICN, 
BGP updates occur rarely (even if we consider update 
storms) and will be sent by known peers. ICN would 
have to apply cryptographic hashing to all Interest pack- 
ets. Cryptographic hash functions are — with respect 
to the packet processing requirements in ICN and cur- 
rent, long-term hardware development — out-of-scope 
also for a future implementation of the ICN paradigm. 

A trade-off between performance and worst-case avoid- 
ance can be implemented by universal hashing 
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has been introduced to obfuscate the hash function by 
randomly selecting the hashing algorithm at start-up. 
Unfortunately, universal hashing is difficult to imple- 
ment in hardware. Moreover, it still shows a collision 
probability which is small compared to basic hashing 
but high compared to cryptographic hash functions. 
Threats based on fingerprinting make the system ad- 
ditionally vulnerable. It should also be noted that uni- 
versal hash tables cannot be deployed in a distributed 
fashion, but are confined to strictly local use cases due 
to the random selection of hash function. Collaborating 
request management is thus challenged. 

For a detailed overview on state-of-the-art hash ta- 
bles for high-speed packet processing, we refer to the 
excellent work by Kirsch et al. [30]. Even though wire- 
speed hash tables are deployed in the current Internet, it 
is by no means obvious that these approaches provide 
sufficient robustness in daily ICN operation. Current 
solutions exhibit serious attack vectors, either by DoS 
collision overwrite or by a non-constant worst-case per- 
formance. In addition, even a constant complexity does 
not guarantee appropriate robustness as extra memory 
accesses can prevent wire speed performance. 



3.3 Discussion 
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ICN approaches introduce three major changes to the 
current, well approved Internet infrastructure: 

1. Information objects become first class routable net- 
work entities. 

2. The control plane of the routing system is opened 
to the end users, who are entitled to implement 
states at routers that are managed by data-driven 
events. 

3. The end-to-end design principle is abandoned in 
favor of of a hop-by-hop routing coordination. 

All of these novelties impose severe challenges to an 
infrastructure serving the needs of a future content- 
centric Internet. While the first change threatens an 
infrastructure design by the mere amount of entities to 
be accommodated, an opening of the control plane gives 
rise to manifold attack vectors. In such an environ- 
ment of a open access to infrastructure states, security 
and robustness measures need to be applied to many 
more constituents of the distribution system than in 
today's Internet. In addition, the requirement of man- 
aging states in line with data forces any of the (user- 
centred) operations at the control plane to run at wire 
speed. The latter is an exceptionally hard challenge, as 
even operations of constant complexity may exceed the 
realm of wire speed processing. 

Finally, the hop-by-hop approach applied in contrast 
to the end-to-end concept promises the advantage of 
early adaptation to changing network conditions. How- 
ever, the problem of resource coordination makes hop- 
by-hop forwarding significantly less robust than solu- 
tions built upon the end-to-end design principle. In fact, 
it is very easy to construct cross-traffic scenarios that 
lead to disastrous performance of hop-by-hop forward- 
ing paths. Lead by this insight, Carofiglio et al. [3l] 
propose to build ICN on a hybrid solution of AIMD 
(additive increase, multiplicative decrease) applied to 
intermediate routers and end points. However, the au- 
thors did not account for effects of delay and delay vari- 
ation between content requests and content fulfillment. 
In addition, aggregation needs to be taken into account 
that spoils the concept of adapting to individual flow 
parameters. 

When examined from the conceptional side, ICN so- 
lutions raise many fundamental problems and — up un- 
til now — fail to resolve the corresponding problems. It 
is the aim of the present paper to identify challenges 
and sharpen the view on issues that require resolution. 
Detailed solutions of the identified problems are out of 
scope for the present work. 

In the following, wc will experimentally evaluate the 
content delivery system for the example of name-based 
routing. To analyze the behavior of the correspond- 
ing infrastructure, we perform only common ICN op- 
erations (i.e., subscriptions of existing and non-existing 




Figure 1: Topology in the experimental setting 

data) in a straightforward topology with a simple con- 
tent model. This allows us to omit side effects due to 
complex routing or caching issues. 

4. EXPERIMENTAL EVALUATION 

In this section, we present the results of straight- 
forward experiments that show the outcome of the core 
threats as theoretically discussed in Section [3] In par- 
ticular, we concentrate on system and performance im- 
plications of the data-driven state management at in- 
frastructure devices. Even though the measurements 
mainly relate to the NDN implementation cend, we 
should emphasize that we do not evaluate the imple- 
mentation itself, but use it as one real-world instance 
of the information-centric network deployment to illus- 
trate the routing protocol mechanisms. Following this 
spirit, we do not interpret or discuss absolute perfor- 
mance values, which surely can be improved by opti- 
mized software and hardware in the future, but focus 
on structural and asymptotic analysis. 

4.1 Core Measurement Setup 

In our measurement study, we purposefully deploy 
simple communication scenarios between one content 
requester and one publisher. The basic network topol- 
ogy is represented by a Daisy chain of directly inter- 
linked CCNx routers with 100 Mbit/s, one end connects 
the content consumer and the other the content reposi- 
tory (see Fig. [I]). The basic topology consists of two hops 
and the extended topology of five nodes. It is noteworthy 
that more complex settings, e.g., a Dumbbell topology 
popular to represent backbone network effects, would 
enforce the effects, which we already see in our simpler 
and more transparent examples. 

We use the CCNx implementation version 0.5.1 
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i.e., the client library to announce content Interests, the 
content repository to store data, and the cend to for- 
ward subscription and data. The following analysis fo- 
cuses on the effects on the router side. For obtaining 
a fine-grained view, we concentrate on the local system 
as well as inter-router dependencies. 

For all CCNx parameters, we leave default values. 
In particular, routers do not follow a specific strategy 
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layer, as this would push resource consumption towards 
specifically twisted but equivalent results as discussed 
in Section [2j This also implies deactivated rate limit- 
ing, which additionally introduces further attack vectors 
(cf., Section 5.3). CCNx routers communicate via TCP 



150k Interests received . Retransmission Only Phase 



(preserving packet order in the basic experiments) or 
UDP (extended experiments). 

4.2 Resource Consumption: Basic Experiments 

4.2.1 A Fast Path to Resource Exhaustion 

An elementary threat intrinsic to data-driven state 
management arises from the overloading of routers by 
Interest requests. This is most easily provoked by ini- 
tiating requests for content that does not exist. In our 
scenario, the consumer issues 2,000 Interest messages 
for non-existing content, waits 6 seconds, and repeats 
these steps until overall 150,000 Interests have been 
sent. 

Figure[2]shows the local resource consumptions on the 
first hop of the content receiver. The number of entries 
in the Pending Interest Table (PIT), the CPU load, and 
the required memory increase linearly with subsequent 
bulks of Interest messages until the system is saturated. 
In this case, the router reaches its limits of processing 
and memory resources when storing ss 120,000 PIT en- 
tries. While sending Interests, the initiating node re- 
transmits previous announcements to keep states fresh 
at the router. Even though the retransmission timer 
is below the expiration timer and network delays are 
very short, the PIT size fluctuates as entries drop due 
to overloading. After all initial Interest messages have 
been distributed, the content consumer only retransmits 
subscriptions. 

Our experiment illustrates several problems: A router 
may easily exhaust PIT space, but even if it was able to 
store all entries, it would suffer from a 'retransmission 
only' phase. The retransmissions agglomerate over time 
and create a continuous stream of signaling that con- 
sumes CPU cycles. When the update rate is higher than 
the processing capabilities permit, retransmissions re- 
quire buffering, which leads to additional memory over- 
head (cf . , Figure [2]) . A high system load increases the 
probability of dropping a PIT entry even if its refresh 
message has been signaled in time. This again causes 
additional operations on the PIT data structure (add/ 
delete calls) and fosters the momentum of load. 
In a recent publication, Yi et al. 



33 



propose to miti- 
gate this threat by signaling content unavailability back 
to the original requester. Such NACK will cure the Inter- 
est retransmission effects discussed above, while at the 
same time NACK suppression introduces a new attack 
vector at the supplier side. Unhindered by the presence 
of NACK, a bogus requester still can harm the routing 
infrastructure (in particular its designated router) by 




100 200 300 400 500 600 700 800 900 1000 1100 
Time [s] 

Figure 2: Load at the designated router of the 
receiver while requesting non-existing content 

subsequent new Interest messages for unavailable con- 
tent. 

4.2.2 Chunk-based State Multiplication 

To analyze the performance of content consumption, 
we conduct a bulk file transfer. At this, the content re- 
ceiver initiates the parallel download of multiple 10 Mbit 
files over a constant time. We consider three extremes, 
the request of 2 files, 10 files, and 100 files per second. 
Figure [3] shows the start and completion time of the 
download per file (top graph), as well as the Pending 
Interest Table (PIT) size, the effective number of Inter- 
est retransmissions, and the traffic load including the 
mean goodput at the first hop. For visibility reasons, 



we rescaled the y-axis of PI in Figure 3(a) 

With an increasing number of parallel downloads not 
only the download time increases significantly, but also 
the interval of the request and receive phase grows in 
the scenarios of overload. While the download time is 



almost constant for two files per second (cf., Fig. 3(a) I, 
the stop time diverges non-linearly from the beginning 
of the download in the cases of excessive parallelism (cf., 
Fig. |3(b) |(c) ). 150 s are needed to download each single 
file in the worst case (Fig. 3(c) I, while the link capacity 



would permit to retrieve all files in about 10 s. 

The reason for this performance flaw is visualized in 
the subjacent graphs. A higher download frequency 
leads to an increasing number of simultaneous PIT en- 
tries, which require coordination with the data plane. 
Each file request will be split into requests of multi- 
ple chunks, in which the generation of corresponding 
Interest messages will be pipelined. In contrast to Sec- 
tion |4.2.1| content exists. As soon as the content tra- 
verses, Interest states dissolve and thus release mem- 
ory. These operations cause a simultaneous burst in 
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Time [s] Time [s] Time [s] 

(a) 2 files per second (b) 10 files per second (c) 100 files per second 

Figure 3: Parallel download of 10 Mbit files: Start and stop time of the download per file at the re- 
ceiver &: resource consumption at its designated router [Pending Interests (PI), Interest Retransmits 
(IR), and Network Load (NL) including the mean goodput] 



CPU load (not shown) and result in growing Interest 
retransmits after droppings or timeouts (shown in sec- 
ond lowest graphs). This also leads to retransmissions 
of data chunks. As an overall net effect, the network uti- 
lization fluctuates significantly, but does not adapt to 
actual user demands: Even though data requests could 
fill the links easily, the average load remains about con- 
stant at 30 % of the total network capacity. 

In this example we demonstrated that insufficient pro- 
cessing and memory resources will strictly prevent a 
proper link utilization. This problem cannot be mit- 
igated by rate limiting, as reduced Interest transmis- 
sion rates will simultaneously reduce network utilization 
even further (see Section 3.2.l| p] 

The only visible way to assure proper utilization of 
network resources requires appropriate routing resources, 
i.e., a PI table implementation that is sufficiently large 
and reliably operates at line speed. As we learned from 
the analysis in Section [3T2| corresponding solutions are 
not available today. At the current state of the art, an 
attacker can always reproduce the performance degra- 
dations by either blowing up RTT and its variation, or 
by injecting states that degrade the performance of the 
PI hash table of the routers. 

4.3 State Propagation and Correlation: 
Extended Experiments 

In our extended experiments, we take a closer look 
at hop-by-hop routing performance using the five node 
routing chain displayed in the lower part of Figure [l] 
Intermediate nodes are numbered from the designated 

7 We should remind that applying Interest rates in NDN is a 
mechanism of flow control, and not for system resource pro- 
tection. Intermingling these two aspects is likely to produce 
unwant ed p erformance flaws and leads to new attacks (cf., 
Section 5.3 1. 



router of the content receiver (first hop) to the router 
of the content repository (fifth hop). In the first step, 
we specicically concentrate on correlation effects of a 
single requester/publisher pair, thereby neglecting any 
competing cross traffic. Instead, we steer and survey 
routing resources in our experimental setup by using 
parametrizable virtual machines. 

4.3.1 Extending the Easy: A Homogeneous Network 

In this first extended experiment, we simply move our 
previous picture to the larger topology. All forward- 
ing nodes offer the same resources, two cores@2.4 GHz, 
3 GB RAM, and link capacities of 100 Mbit/s. A con- 
tent requester downloads 500 files of size 10 Mbit at an 
average rate of 100 files per second. 

The corresponding results are visualized in Figure |4j 
It is nicely visible, how Interest state and retransmis- 
sion management propagate through the network, show- 
ing an overall flattening towards the source, because 
states resolve earlier from faster packet delivery. Re- 
source challenges due to state management as discussed 
in Section [4.21 lead to an accumulated reduction in net- 
work utilization. The network goodput decreases from 
« 30 Mbit/s to ps 8 Mbit/s, a reduction that is about lin- 
ear in the number of hops. Correspondingly, the down- 
load times increase from rj 150 s to ps 250 s. 

4.3.2 Device Heterogeneity: A Single Point 
of Weakness 

It is a valid assumption that the content distribution 
system will consist of heterogeneous devices in terms 
of all performance metrics. In this second experiment, 
we introduce device heterogeneity by weakening a single 
router, the 4th hop (CCNx4), in a controlled way. We 
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Time [s] Time [s] Time [s] 

(a) Pending Interests (b) Interest Retransmits (c) Network Utilization 



Figure 4: Routing and forwarding performance in a homogeneous five-hop network 
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Figure 5: Load per hop for a chain of 5 routers 
while initiating a 80k, 100k, 120k, and 150k dif- 
ferent Interests for non-existing content 



want to study the reaction of state management and 
network performance to this well-defined degradation. 

For an initial observation of the dependency on the 
weakest node, we reduce the CPU capacity of CCNx4 
to 25 % (600 MHz) and recap the scenario from Sec- 
tion |42l] for 80k, 100k, 120k, and 150k subscriptions of 



non-existing content. Independent of the capacity of the 
network infrastructure, the consumer initiates content 
subscriptions and continuously refreshes its Interests, 
which then propagate towards the content repository. 

Figure [5] shows the maximal memory consumption 
and the average CPU load per hop during the measure- 
ment period. It is clearly visible that the required mem- 
ory mainly depends on the position of the node within 
the topology. Memory requirements on the single path 
fluctuate by two orders of magnitude. The predecessor 
of the node with the lowest processing capacities (i.e., 
the 4th hop) needs 50% - 500% more memory than any 
other nodes. 

In this scenario of reliable transport for signaling mes- 
sages, a bottleneck node puts pronounced load onto its 
predecessor as the forwarding of the refresh messages 
retain. The reason for this strongly unbalanced perfor- 
mance picture can be found in RTT fluctuations: The 
weak on-path router appears like a periodically effec- 
tive blockade for Interest transmission. In general, het- 
erogeneous network conditions lead to a discontinuous 
propagation of Interest states and thus to a fluctuating 
performance. The successors of the weak router then 
do not receive state updates in time, and the predeces- 
sors experience large waiting periods. Correspondingly, 
the results displayed in Figure [5] impressively demon- 
strate the effects of time fluctuations in content-centric 
routing. 

4.3.3 Steady-State Stability 

In the next step of our analysis, we take a closer look 
on gradual effects of routing heterogeneity. We observe 
corrective mechanisms of the network (i.e., Interest re- 
transmissions) depending on router asymmetry. Inter- 
est retransmissions serve as the key indicator for time- 
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Figure 6: The effect of router strengths on In- 
terest trading 



outs due to router overload. For this task, we configure 
CCNx4 with four different processing capacities related 
to the other CCNx routers: 2,400 MHz (homogeneous), 
1,200 MHz (50% capacity), and 600 MHz (25% capac- 
ity). 

Surprising results are shown in Figure [6] Evidently 
we see that network behavior switches on the occurrence 
of router heterogeneity, independent of its strengths. 
The characteristic behaviour of the balanced network 
is a steady decay of Interest retransmits towards the 
source, as data delivery gets faster and more reliable 
in proximity to the publisher. However, at the first 
occasion of a 'bottleneck', the picture flips. Interest re- 
transmission drastically increases and all routers except 
for the bottleneck equally see about the maximal rate of 
retransmissions in this scenario. State retransmissions 
at the weak forwarder (CCNx4) instantaneously dou- 
bles to the level of managed states this router can cope 
with. 

This experiment clearly shows how sensitive content- 
centric routing reacts to varying network resources. A 
light disturbance of the state propagation process re- 
veals the instability of a steady-state flow by immedi- 
ately turning content transport into a significantly dif- 
ferent condition of maximal error management. 

4.3.4 Complex Inhomogeneities 

In our final experiment concerned with content rout- 
ing, we want to explore situations of largely decorre- 
latcd network conditions. Therefore we configure all 
routers to admit fast changing resources occurring in 
anti-cycles. In detail, each intermediate router (CCNx2, 
. . . , CCNx4) is forced into a periodic CPU reduction by 
90% of 30 s. Resource reduction periods were shifted 
between routers by 15 s so that at least one of the three 



routers in the forwarding chain was kept in challenged 
conditions. The objective of this repelling setup, which 
similarly may well occur from different side traffics in 
a meshed backbone, is to analyse the vulnerability of 
hop-by-hop state maintenance in content-centric rout- 
ing. 

Results of this alternating resource scenario are dis- 
played in Figure [7] Visualisation is completely analo- 
gous to the initial view on a homogeneous network (see 
Figure [4]). The course of pending Interests as well as In- 
terest retransmissions open a distinguished view on the 
fine-grained sensitivity of content routing to neighbor- 
ing router conditions. State provisioning fluctuates on 
the resource resolution scale of 30 s throughout the net- 
work. More importantly, data transmission rates drop 
down to about 2.4 Mbit /s, while the overall load of In- 
terest states remains compatible to the homogeneous 
network. Uncoordinated network resource availability 
thus leads to a low overall performance in conjunction 
with high network resource consumptions. Time-to- 
completion for each single file download correspondingly 
explodes to 900 s for the same 10 Mbit files as in our 
initial experiment. It should be recalled that network 
capacities do allow for a simultaneous download of all 
500 files within 10 s. 



4.3.5 A Comparative Summary 

In the different scenarios of our experimentally-driven 
analysis, we have revealed a number of structural weak- 
nesses and effects immanent to the current state of content- 
centric routing in heterogeneous multi-hop scenarios. 
All examples lead to severe service degradations. Nev- 
ertheless the question arises on how these insights com- 
bine to a consistent view. 

We will try to present an overall picture in the fol- 
lowing. Figure [8] contrasts the load imposed onto the 
infrastructure by Interest states with the average net- 
work performance in the three experimental scenarios, 
homogeneous network, single point of weakness, and al- 
ternating resources at routers. The striking picture in 
all three settings is that the efficiency of network utiliza- 
tion is low on the overall, but drastically drops when- 
ever inhomogeneities occur. The hop-by-hop forward- 
ing performance thus must be considered rather fragile. 
In contrast, network state propagation attains various 
patterns, but always remains at compatible level at the 
router of maximal load. 

These observations suggest the following rule of thumb 
for CCN routing performance: State maintenance al- 
ways follows the maximal requirements, while forward- 
ing performance will adapt to the weakest resource in 
place. This overall picture is clearly inefficient and fu- 
ture work on ICN solutions would largely benefit from 
improving this behaviour. 
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Figure 7: Routing and forwarding performance in a five-hop network with alternating CPU reductions 
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(b) Single Point of Weakness 
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Figure 8: Comparison of state management and forwarding performance in different network scenarios 
(mean and standard variation) 



5. EXAMPLES OF ATTACK SCENARIOS 

In this section, we will outline and briefly discuss new 
attack scenarios that arise from data-driven state man- 
agement in ICN. We will illustrate these examples by 
terms related to our experiments on CCNx (e.g., PIT), 
but should emphasize the general applicability to sub- 
scription resp. publication states as discussed in Sec- 
tion H 

5.1 Attacks Related to Resource Exhaustion 

As shown in the previous section, routing and for- 
warding capacities of the infrastructure can be easily 
compromised by overloading its content request or inter- 
est tables. As non-aggregable name requests for locally 
unavailable content propagate through the network, re- 
source exhaustion attacks can be transparently initiated 
from the remote. For this purpose it remains completely 
indifferent whether hardware resources are drained at 
unrestricted PIT sizes or table space exhausts accord- 
ing to various limiting configurations. Correspondingly, 
FIB overflows at routers occur in response to excessive 
publications or updates of names. Details of the at- 
tacker's effects depend on the state-dropping strategy — 
for simplicity we assume dropping tails as used by CCNx. 
In addition, virtual resources may also be depleted. The 
injection of bogus Interests disturbs ICN flow control 



mechanisms at routers, for example, because it reduces 
request limits. 

Remotely Initiated Overload An attacker that 
controls one or more machines (a botnet) may initiate 
massive requests for locally unavailable content. Corre- 
sponding interests propagate towards the publisher and 
eventually accumulate at some content router causing 
overload conditions. Depending on its intensity, this 
attack will lead to a service impairment or DoS for the 
(remote) content distribution tree(s) branching at the 
degraded router, unless the networking system is able to 
re-route the requests. It is worth noting that timeouts 
at regular users on the subtree will initiate retransmis- 
sion 'storms' and thereby amplify the attack. 

Piling Requests due to a Slow Source Perfor- 
mance of a content source may be degraded by artifi- 
cially high numbers of direct requests causing slowed 
down responsiveness. Alternatively, a captured source 
or its overloaded access router may drastically increase 
response times of content delivery. In slowing down 
a (popular) source, an attacker lowers the data return 
rate and thereby the extinction of pending interests at 
all routers on paths to receivers. Thus attacking a sin- 
gle point may result in a widely increased load at the 
routing infrastructure. 

Mobile Blockade A mobile node (MN) may issue 
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a large number of invalid interests that block the PIT of 
the mobile access router for the period of state timeout. 
In a shared link-layer environment that cannot easily 
detect its departure, the mobile adversary can traverse 
neighboring networks on circular routes and continue to 
offload its interest bundle with the effect of a blockade 
of the regionally available networks. Initial counter- 
measures are difficult to apply, as the retransmission of 
interests is part of the regular mobility pattern in ICN. 

Fooling Rate Limiting Current ICN approaches [3] 
propose rate limiting to restrict the number of Interest 
states. Its main purpose is flow control to avoid con- 



gestion. In contrast to common believes (see 20 for 
discussions) we argue that this is not an appropriate 
countcrmeasure to protect the ICN distribution system 
against attacks. An attacker can easily create an in- 
terest storm that exceeds the anticipated interest limit. 
The dedicated router will throttle the number of ac- 
cepted interests per interface or interface+prefix, and 
finally ignore subsequent interests. Consequently, a sin- 
gle end user blocks a prefix or harms all members of its 
domain. 

Note, applying rate limiting per end host (or user) is 
non-trivial in ICN. ICN explicitly discontinues the con- 
cept of host identifiers (e.g., due to security reasons). 
Thus, a router cannot track particular sources that send 
an unexpected amount of interests. Even if routers are 
enabled with such a function, an attacker can spoof ad- 
dresses. 



The same holds for push-back mechanisms 20 , which 



signal an overload towards the source and thus try to 
isolate an attacker. In addition, an attacker that would 
receive such a control message can ignore it. 



5.2 Attacks Related to State Decorrelation 

ICN requires consistent states during the request rout- 
ing phase and the asynchronous content delivery. While 
bogus announcements or flapping of routes may intro- 
duce loops or increase the likelihood thereof, incoherent 
forwarding paths may result in partial content trans- 
mission that uses network resources without success in 
data delivery. 

Infringing Content States An attacker that con- 
trols end systems or content routers could announce up- 
dates of content or cache appearances at a frequency 
that exceeds the (local) content request routing con- 
vergence time. As a consequence, the overloaded an- 
nouncement or mapping system will be unable to cor- 
rectly process the updates of proper content sources or 
caches with the effect of incomplete content represen- 
tation and erroneous data replication states. Content 
requesters will be thus led into false retrievals or access 
failures. As content announcement is commonly built 
on soft-state approaches, failures will eventually time- 



out after a period of undisclosed inconsistency, which 
the adversary could initiate in a momentary attack. 

Timeout Attack The timeouts of pending inter- 
ests fire independently in a distributed network envi- 
ronment, which is normally healed by early refreshes. 
An attacker that controls one or more machines may 
interfere with state coordination by degrading the per- 
formance of two or more on-path routers so that request 
routing and data forwarding exhibit large, fluctuating 
delays in the order of the timeout. As a consequence, 
intermediate timers will erase interests with large prob- 
ability prior to data delivery or retransmission requests. 
Corresponding receivers will suffer from DoS for the af- 
fected chunks or arbitrarily large transmission delays. 

Jamming Attack A node on a shared link may 
issue a large number of content requests without main- 
taining the interests at its own (loosing interest). Con- 
tent will then arrive at the local link without a receiver. 
This scenario is particularly harmful in mobile environ- 
ments of limited bandwidth. A mobile attacker can jam 
a region by traversing shared radio links while request- 
ing bulk data. 



5.3 Attacks Related to Path and Name Infil- 
tration 

ICN raises content names and cache locations to first 
class objects and must therefore remain open to naming 
and placing data. The request routing system carries 
routes to names in its FIB or a mapping service, both of 
which are vulnerable to resource exhaustion and route 
poisoning. While an explosion in the pure number of 
names may be mitigated in parts by aggregation ac- 
cording to some authoritative naming conventions like 
in today's domain names, bogus route infiltration must 
be considered the more delicate issue. 

Route Hijacking An adversary may announce (or 
register) routes to cached copies of any content object. 
Content requests from its vicinity are then directed to- 
wards the malicious system and - if unanswered or re- 
tarded - lead to long-lasting forwarding states and a 
possible DoS. This threat can be mitigated by resource- 
intensive attempts to route towards multiple locations 
that become increasingly painful when an attacker con- 
trols a botnet and injects invalid routes at large scale. 

Route Interception Alternatively, an adversary 
may keep record of the valid routes to the content, while 
it announces various malicious routes. Content requests 
can then be intercepted and forwarded to the proper 
location. The intruder will thus gain knowledge of the 
content consumed in the networks under attack, while 
receivers experience a normal network behavior. This 
privacy violation may allow for highly selective infor- 
mation, whenever the attacker is topologically close to 
the victim. 
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6. CONCLUSIONS & DISCUSSIONS 

In this paper, we have analyzed network instabilities 
in information-centric networks that are caused by (a) 
data-driven state management and (b) backbone states 
initiated by end users. 

Some threats are easy to anticipate (e.g., resource ex- 
haustion), others are more intricate due to the complex 
interplay of distributed states (e.g., state decorrelation). 
For the latter previous practical insights in the design 
of (conceptually related) multicast protocols already re- 
vealed good and bad design options. One of the ma- 



jor design goals of Bidirectional PIM 34 , for example, 



was „eliminating the requirement for data-driven proto- 
col events" — after the operating experiences with data- 
driven DVMRP or PIM-SM. We are somewhat puzzled 
that those insights seem to have been ignored by the 
ICN community. With this paper we want to stimu- 
late the discussion about basic threats and attacks on 
content-centric backbone routing. We admit that re- 
solving the identified problems is definitely challenging 
as this either reduces capabilities of the ICN infrastruc- 
ture or flexibility at the end user. 

The exhaustion of memory and processing resources 
following excessive state allocations and manipulations 
was identified as one major reason for service degra- 
dation and DoS attacks. An obvious approach to mit- 
igate the resource exhaustion problem is to limit the 
rates of state injection into the network. Applying re- 
strictions per domain (e.g., [33] ) will create new attack 
vectors from the interior, while limiting users will re- 
quire tracking of end nodes and leads to traffic shaping 
and bandwidth restrictions. As content states will accu- 
mulate in the network, and inter-provider deployment 
almost surely will lead to a heterogeneous, unbalanced 
design, rate limiting may milden, but cannot effectively 
prevent the resource exhaustion problems discussed in 
this paper. 

The other major threat to ICN stability arises from 
the ease of malicious name or route infiltration. Even 
though similar vulnerabilities are known from BGP, ICN 
backbones will be populated by data-centric states — 
created, modified or deleted by any end-user of the 
network — and thus largely magnify the problem scope 
of poisoning the control plane. 

Current CDN deployments remain agnostic of these 
infringements by running under proprietary regimes. 
Still, if we want the Future Internet to remain open for 
every content published by any user, we cannot impose 
restrictions that approach today's CDN regulations in 
any way. 
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